home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / September 96 / Offscreen GX and Hi-res Printin < prev    next >
Encoding:
Internet Message Format  |  1996-09-19  |  3.1 KB  |  [TEXT/ttxt]
  1. Subject:     Offscreen GX and Hi-res Printing
  2. Sent:        9/3/96 5:14 PM
  3. Received:    9/3/96 5:14 PM
  4. From:        msandber@Sigma4.com (Martin Sandberg)
  5. Reply-To:    ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List
  7.  
  8.  
  9.         I have two somewhat related questions.  First, does anyone have any
  10. insights into imaging using QuickDrawQX into ODF's offscreen bitmaps?  How
  11. should I go about connecting QDGX with one?  We really need to do offscreen
  12. rendering for redraw speed and general cleanliness and GX has such _useful_
  13. capabilities <G>.  Has anyone had any experience with this?  Or
  14. suggestions?
  15.         As I understand using QDGX in ODF, I would normally (after testing
  16. for the presence of QDGX, of course) just build an FW_CGraphicsContextGX in
  17. the Frame's Draw method each time Draw is called and pass that to a bunch
  18. of custom Render methods that take it as a parameter.  Or is there a better
  19. way?  And how does the QDGX GC relate to the many different types of
  20. GraphicsContexts that are derived from FW_CGraphicContext?  Are there cases
  21. where, say, an FW_CViewContext (or any of the others in FWContxt.h) has
  22. needed capabilities not found in the GX context (which does NOT descend
  23. from the same class??)  ?
  24.  
  25.         Second question: last weekend (Labor Day is a work day, right?) I
  26. was investigating how ODF handles high-resolution output devices like laser
  27. printers and ink jets.  Screens are not, after all, the only output
  28. devices..
  29.         I was reviewing the way the ODF private render system works (in
  30. SLRender.cpp) when something struck me.  All of the shapes that are
  31. rendered thru this system are reduced to QuickDraw resolution (i.e., short
  32. coordinatess where 1 represents a point or 1/72 inch).  Doesn't this mean
  33. that printing, also, is limited in its resolution on, at least, the Mac
  34. side?  (I didn't check on the Windoze code)
  35.         This seems to me to indicate that all the effort of using ODF
  36. fixed-point coordinates for graphics is just wasted when it finally comes
  37. to putting dots on a screen or on paper.  I understand this on the screen
  38. side since, after all, a screen has limited resolution.  However, what
  39. about print output?  Did I miss something about when printing happens that
  40. does use the fractional-point portion of the coordinate information?
  41.         I understand that ODF is always going to be a thin graphics layer.
  42. I accept that (grumble, grumble <G>).  I had assumed that this meant that
  43. fancy graphics shapes (e.g., rotated text) were our problem.  However, I
  44. had assumed that what was we saw in the code was actually used, e.g., in
  45. the case of FW_Fixed coordinates.  So why does ODF throw away the result of
  46. all the extra work involved in fixed-point math when it could be used if,
  47. e.g., QuickDrawGX is available for printing?  How do I explain to my users
  48. that I let them set a 0.5 point pen size but printed out a 1 point wide
  49. line instead on a 600 dpi laser printer?
  50.         It looks to me as though ODF's imaging model (at least on the Mac
  51. side) is really intended mostly for screen display.  Is this a correct
  52. assumption?  Do I have to write my own set of renderers if I wish to
  53. support high resolution output devices?
  54.  
  55. Thanks,
  56. Martin